Embodiments of the present invention generally relate to storing and accessing information from various sources, and more particularly relate to a hierarchical and distributed data repository system containing said information.
Presently, one of the most pressing problems met when developing, testing, and deploying products, applications, and/or services for devices such as mobile devices (e.g., cell phones, PDAs, mobile computer devices), and which can run on a server and/or these devices and be accessible to both, is the lack of information about the particular delivery channel or device/channel delivery context. Various properties of a mobile device, such as the operating system, amount of available or installed memory, form factor of the screen, and capabilities/type/version of the browser, are of interest to entities such as service providers or mobile application developers, as it is desirable for the service or application to function properly on the device.
This problem has been recognized by a number of entities, such as the World Wide Web Consortium (W3C) and the Open Mobile Alliance (OMA), which have tried to partially address the issue, such as by introducing the W3C WG common Rule Interchange Format for the Web which provides the ability to exchange and merge rules from different sources. Further, the Composite Capabilities/Preference Profiles (CC/PP) infrastructure can be used to describe device capabilities and user preferences, or a device's delivery context, which aids in the adaptation of content presented to a device. The User Agent Profile (UAProf) specification, for example, is one way implemented currently to concretize the CC/PP details, although the actual standards or non-standards used are not critical to the embodiments described and suggested herein. Java Specification Request (JSR) 188 provides a specification that can be used to support such mechanisms. While current such mechanisms provide access to some device/channel information, such context information is often lacking, incomplete or even incorrect.
Due to the incompleteness and inaccuracies in such information, companies and private initiatives are compiling repositories containing additional and/or hopefully more accurate information. However, these repositories often are based on information inferred on the device or channel by the owner of the repository, and may also be relatively inaccurate or incomplete. Further, these repositories inherently lag the deployment of new devices, as approaches to handling and dealing with these devices can typically only be determined after obtaining and experimenting with such a device. It is with such new devices that the problem is the most acute, as it is desirable to make sure that a brand new device is supported by a product or application, that the product or application can be accessed by the hot new device (e.g. what XSLT to use or define), and that the product or application will be useful and desirable to a particular user of this new unknown device.
For example, an developer of applications for mobile devices typically will want to make sure that the applications run properly on as many mobile devices as possible. As shown in the configuration 100 of FIG. 1(a), a service provider 104 or application developer 106 might desire to have an application or service run on each of a laptop computer 110, PDA 108, and cell phone of a first provider or manufacturer 112 and a cell phone of a second manufacturer or provider 114. In one example, the application is provided by an application server 116 (or Web server or other appropriate device as known in the art) that can access data in an appropriate database 118 to provide the application over a network 102, such as a cellular network or other wireless network.
One approach currently used for device adaptation for mobile and voice access takes advantage of the fact that applications can be authored for different types of access using a single application development model, such as an ADF faces module from Oracle International Corporation of Redwood Shores, Calif., providing user interface components based on the JavaServer Faces technology. Such an approach is shown in the arrangement 120 of FIG. 1(b), wherein a J2EE container 126 including JSF components and having access to application database in a database 128 can serve pages for display using various clients 122, 124. Adaptation to channels and/or devices is performed via dedicated RenderKits used in the ADF cycle (such as in the Renderer). A consistent J2EE programming model then can be used for pages designated for the various devices, in an environment such as Oracle's JDeveloper, which provides end-to-end support for modeling, developing, debugging, optimizing, and deploying Java applications and Web services. Levels in such an environment are illustrated in the arrangement 140 of FIG. 1(c). In such an environment, phone and voice applications may rely on dedicated RenderKits, or RenderKits for Device Independence (DI) authoring and an appropriate adaptation engine in the appropriate levels 142. An ADF mobile approach built on JSF provides for a single development model across agents, using a component-based architecture. Various RenderKits can provide for agent-specific rendering. Approaches also can utilize a Java Server Faces implementation such as the open source MyFaces implementation from the Apache Software Foundation, which provides an extensive set of components, desktop and PDA RenderKits, Agent capability reporting, and skinning capabilities.
The need for such complexity comes from the fact that, unlike personal computers, which typically utilize only a handful of standard operating systems and require only a small level of compensation for different configurations, mobile devices such as PDAs and cell phones utilize many different operating systems, form factors, configurations, memory allotments, sizes, input options, etc. Further, devices from a particular manufacturer might be customized for a particular operator or provider, such that a particular cell phone model from a given manufacturer might have a different configuration when provided through a first telecommunications company than when provided through a second telecommunications company. For example, a RAZR V.3 phone from Motorola of Schaumburg, Ill. might be configured differently to work for a Verizon network setup than for a Sprint network setup, and may include different software. Further, a Nokia phone might have a different configuration for a Verizon network setup than a Sony or Ericsson phone for the same network. Further still, a user or operator might alter the configuration of the mobile device, such as by adding memory, changing the operating system, etc., as well as altering the software on the device While user customization of such devices has been relatively limited to this point, the ability to customize will continue to increase as time goes on, which may require access to information that is specific to a given device or user.
In order to provide applications or services that work as desired on multiple such devices, there then are multiple types of device information that may be worth collecting. While a device manufacturer may publish, through a specification or documentation of the device or through a device repository, information about the characteristics of the device, such as compatible networks, operating frequencies, form factor, and browser version, this information may not be accurate, as a mistake may have been made or information may not have been properly updated between releases for a given device number or model, or because the device has been further customized by an operator, user, or other party. Further, for business reasons, the device manufacturer may not necessarily be interested in providing all the information about the device, or providing completely accurate information. As a result, other service providers or vendors have found it advantageous to collect information about these device themselves. These entities may build databases themselves that contain at least some of the data obtained from the manufacturer, as well as information that these entities have obtained themselves about the devices, such as through testing and experimentation. These entities often sell this information to other service providers, application providers, or vendors who want to build applications or provide services that can be adapted appropriately to the device. When the information is device and/or user specific, however, regulatory and/or privacy considerations may prevent or limit the providing of full and/or unprotected/uncontrolled access to such information.
Even though these entities may collect additional information, they still may not provide accurate or up-to-date information for all devices, particularly where those devices are customized by a user or operator. Even if the information is correct for a particular manufacturer or vendor, the information may not be accurate for particular devices.